home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1996 #14 / Monster Media No. 14 (April 1996) (Monster Media, Inc.).ISO / netmail / mplus400.zip / MFIX433.ZIP / MAILFIX.DOC < prev    next >
Text File  |  1995-02-02  |  18KB  |  386 lines

  1.                               MAILFIX v4.33
  2.                               -------------
  3.  
  4.    MAILFIX is a purge/repair/renumber utility for RBBS-PC message bases.  It
  5.    was originally written by Chip Morrow and released as part of the MAIL
  6.    MANAGER offline mail door for RBBS-PC, but because of its obvious utility
  7.    for all RBBS sysops, whether running MAIL MANAGER or not, we are releasing
  8.    it as a free, separate stand-alone utility.  Version 4.0 was largely
  9.    rewritten by Doug Wilson to run much faster than previous releases, and
  10.    has a few more useful options than previous versions.
  11.  
  12.    Significant changes and additions in this document from release 4.32 are
  13.    indicated by a | symbol in the left margin.
  14.  
  15.  
  16.    WARRANTY, DISTRIBUTION, AND LICENSING AGREEMENT:
  17.    ------------------------------------------------
  18.  
  19.    MAILFIX is 100% guaranteed to take up space on your hard disk, and is
  20.    equally guaranteed to consume less space if deleted.  MAILFIX is NOT
  21.    guaranteed to do anything else.  Period.
  22.  
  23.    MAILFIX is copyrighted 1991-1995 by Makai Software, all rights reserved.
  24.    We are releasing it with source code, for those who would like to see how
  25.    it operates.  You may distribute it freely, provided that no modifications
  26.    have been made.  You are free to modify the code for YOUR OWN USE in
  27.    whatever manner you wish.  We are sure that the current code is far from
  28.    optimal, but it does seem to work pretty well, nonetheless.
  29.  
  30.    MAILFIX is not "SHAREWARE", rather it is distributed freely with source
  31.    code for other RBBS-PC sysops, as a contribution to the RBBS-PC community.
  32.    See the top of the source code file MAILFIX.BAS for additional licensing
  33.    information.
  34.  
  35.  
  36.    SO WHAT'S NEW?
  37.    --------------
  38.  
  39. |  Not too much, actually.  Version 4.33 provides some further evolution of
  40. |  the handling of exceptionally long messages as can be inserted by message
  41. |  tossers from time to time.  Internal changes now greatly reduce the
  42. |  likelihood that a long message might get truncated by MAILFIX.  When this
  43. |  DOES happen, though, the following message should still start at its
  44. |  proper place in the file, and the balance of the file should not be
  45. |  corrupted.
  46.  
  47. |  Version 4.33 also includes internal compatibility with the file formats
  48. |  used in MAIL MANAGER +PLUS+ 4.00 (which is still in beta stage at this
  49. |  writing).  If you use the message base renumbering capabilities of
  50. |  MAILFIX, it will automatically update the appropriate MAILMGR auxiliary
  51. |  user files (don't worry, this will all make sense when MPLUS400 is
  52. |  released <G>).
  53.  
  54.  
  55.    CONTACTING THE AUTHORS:
  56.    -----------------------
  57.  
  58.    Due to the transitory nature of many bulletin boards, and the fact that
  59.    you may be reading these instructions a long time after they are written,
  60. |  we hesitate to mention a whole raft of bulletin boards where we may be
  61. |  reached.  Inevitably, whichever board we cite will immediately go out of
  62. |  business, and the phone number will be reassigned to somebody who does not
  63. |  care to be awakened by the phone ringing in the middle of the night when
  64. |  we modem junkies place most of our long distance calls.  It is hoped,
  65. |  however, that the board being run by one of the authors, Chip Morrow, will
  66. |  be a relatively permanent establishment:
  67. |
  68. |             INFORMATION OVERLOAD
  69. |             614-837-0739
  70. |             Up to 28.8K V.FC
  71. |             1:226/730
  72. |
  73. |  The authors can also be found on the "RBBS-PC" conferences carried by
  74.    Fido and RIME.  New releases are always announced in these conferences,
  75.    and we occasionally post lists of the currently active distribution sites
  76.    there.  If you wish to contact us via these conferences, address messages
  77.    to Doug Wilson or Chip Morrow.
  78.  
  79.    Current Makai Software releases are always sent to Compuserve within a few
  80.    days of release, in the IBMBBS forum (GO IBMBBS).  The doors themselves
  81.    may be found in library 3, while the individually-distributed utilities
  82. |  (MNET, MAILFIX, etc.) may be found in library 2.
  83.  
  84.    We can also be reached via several other services:
  85.  
  86.        Fido netmail:  1:226/1420                             (Doug Wilson)
  87.        Fido netmail:  1:226/730 or 1:226/1420                (Chip Morrow)
  88.            Internet:  doug.wilson@f1420.n226.z1.fidonet.org  (Doug Wilson)
  89. |          Internet:  chip@infinet.com                       (Chip Morrow)
  90.  
  91.    And if all else fails, there's always good ol' U.S. Mail:
  92.  
  93.                        Makai Software
  94.                        870 Golden Drive
  95.                        Newark, OH 43055
  96.    ------------------------------------------------------------------------
  97.  
  98.    LIMITATIONS:
  99.    ------------
  100.  
  101.    MAILFIX can handle, by default,  RBBS message bases which contain up to
  102.    1000 messages.  When it hits message 1001, it will exit with an error.
  103.    You can increase MAILFIX's internal buffer by specifying /Snnnn on the
  104.    command line, where "nnnn" is the maximum number of messages that MAILFIX
  105.    should expect.  So, if you'd like MAILFIX to be able to handle a message
  106.    base containing as many as 3,000 messages, your command line would
  107.    include:
  108.  
  109.        /S3000
  110.  
  111.    The program would then not error out until it hits the 3,001st message in
  112.    that area.  With the /S switch, MAILFIX is compatible with RBBS mod
  113.    packages which allow far greater than stock RBBS 17.4's limit of 999
  114.    messages per conference.
  115.  
  116. |  Exceptionally long messages (about 4k or longer) may occasionally be
  117. |  truncated by MAILFIX, although the likelyhood of this occurring should be
  118. |  greatly reduced with this release.
  119.  
  120.    Aside from the above, MAILFIX has taken about anything we have thrown at
  121.    it, as long as the file contains consistent 128-byte records.  If
  122.    something should insert or lose characters such that the 128-byte record
  123.    length is not preserved, MAILFIX will not be able to process the file.
  124.  
  125.    ------------------------------------------------------------------------
  126.  
  127.    USAGE:
  128.    -----
  129.  
  130.    MAILFIX [options] D:\PATH\MESSAGE.FIL
  131.  
  132.    Available options (must be separated by a space):
  133.  
  134.        /D - Use DOS screen writes instead of direct.  Slows the program
  135.             down a tad, but allows for DOS redirection of output.
  136.  
  137.        /F - Informs MAILFIX that this is a fixed-length message base.  If
  138.             "/F" is not specified, MAILFIX assumes the message base to be
  139.             configured as 'elastic'.
  140.  
  141.        /Kn - (where "n" is the number of messages to keep.): Tells MAILFIX
  142.             to trim down the physical size of the message base, keeping the
  143.             last "n" active messages.  This is useful for things like an
  144.             echo area that grows almost out of control daily. If you want
  145.             to keep 50 messages, your switch would be "/K50".
  146.  
  147.             This switch may not be used in conjunction with "/V"!
  148.  
  149.             Use of this option will OVERWRITE your original message file!
  150.  
  151.        /N - Tells MAILFIX to renumber the message base, starting at message
  152.             number 1.  If used with the /K option, the retained messages will
  153.             be renumbered starting with 1.  Message pointers for the users of
  154.             that base will also be updated to reflect the new message
  155.             numbers.
  156.  
  157.             Use of this option will OVERWRITE your original message file!
  158.  
  159.             After renumbering the base, MAILFIX will reset the user's
  160.             message pointers to reflect the renumbering.  A default user
  161.             filename in the form xxxxxU.DEF will be derived from the message
  162.             filename specified on the command line, and in the same
  163.             directory as the message file.  To specify a different user
  164.             filename, you may may immediately follow the /N with the
  165.             drive:\path\filename of the user file for this message base.
  166.             There can be no spaces between the /N and the beginning of the
  167.             filename.  Your original user file will be updated in place, so
  168.             if you want a backup of your unaltered user file, you must make
  169.             one first.
  170.  
  171.             If MAILFIX cannot find the default or specified user file, the
  172.             message base will not be renumbered, although other operations
  173.             will continue, as specified on the command line.
  174.  
  175.        /O - Informs MAILFIX that the sysop uses OverMail on this message
  176.             base.  OverMail formats the time field in the message header
  177.             with a semicolon instead of a colon, which CONFIG's option #185
  178.             (repair messages) chokes on.
  179.  
  180.        /P - Tells MAILFIX to purge active personal messages which have been
  181.             received by the addressee.
  182.  
  183.        /R - Informs MAILFIX that the sysop uses RBBSMail or MsgToss on this
  184.             message base.  Both of these mail processors format the time
  185.             field in the message header with a period instead of a colon,
  186.             which CONFIG's option #185 (repair messages) chokes on.
  187.  
  188.       /Sn - (where "n" is the max number of messages that could be contained
  189.             in this message base).  The stock RBBS-PC maximum is 999, and the
  190.             default here is 1000 if /S is not specified.  If you are running
  191.             a modified copy of RBBS-PC (one that can handle more than 999
  192.             msgs per message file), then you will need to use this switch to
  193.             increase MAILFIX's internal buffer.
  194.  
  195.        /V - Only View the integrity of the message file.  Do not perform
  196.             the actual repair work, and do not create an output file.
  197.  
  198.      /Wx: - Define a work drive for MAILFIX to use when creating temporary
  199.             work files.  If the specified work drive does not have enough
  200.             room, the directory containing the message file will be used
  201.             instead.
  202.  
  203.        D:\PATH\MESSAGE.FIL is the name of the messages file to purge/repair.
  204.  
  205.        Unless the /V option is used, MAILFIX will create an output file
  206.        with the same name and the extension '.FIX'.  Above example would
  207.        create D:\PATH\MESSAGE.FIX.  If a work drive is specified which has
  208.        enough free space, MESSAGE.FIX would be created in the work drive
  209.        instead.
  210.  
  211.        If the /Kn or /N switches are used, MAILFIX will make a second pass
  212.        on your message base, using the *.FIX file for input, and the
  213.        original file name for output.  When finished your original message
  214.        file will have been replaced by MAILFIX's work, and the *.FIX file
  215.        will be deleted.
  216.  
  217.    EXAMPLES:
  218.    --------
  219.  
  220.    Unless you use the "/Kn" or "/N" command line options, MAILFIX will not
  221.    overwrite (or modify in any way) your original message file.  If you
  222.    want to replace your old message file with the one that MAILFIX creates,
  223.    your best bet is to run MAILFIX from a batch file, like so:
  224.  
  225.        IF EXIST C:\RBBS\MAINM.FIX DEL C:\RBBS\MAINM.FIX
  226.        MAILFIX C:\RBBS\MAINM.DEF
  227.        IF EXIST C:\RBBS\MAINM.FIX DEL C:\RBBS\MAINM.DEF
  228.        IF EXIST C:\RBBS\MAINM.FIX REN C:\RBBS\MAINM.FIX C:\RBBS\MAINM.DEF
  229.  
  230.        On the other hand, if you have an echo area named 4SALE that's
  231.        scanned by RBBSMail, and you want to keep it purged down to 100
  232.        messages, your command line would be:
  233.  
  234.           MAILFIX /R /K100 C:\RBBS\4SALEM.DEF
  235.  
  236.        If you want to also renumber the message base, and to update
  237.        the pointers in your user file for this base:
  238.  
  239.           MAILFIX /R /K100 /N C:\RBBS\4SALEM.DEF
  240.  
  241.        If you wanted to do the same thing with a message base that's
  242.        been scanned by OverMail:
  243.  
  244.           MAILFIX /O /K100 /N C:\RBBS\4SALEM.DEF
  245.  
  246.        If you wanted to do the same thing but use ramdrive e: as a work
  247.        drive:
  248.  
  249.           MAILFIX /O /K100 /N /WE: C:\RBBS\4SALEM.DEF
  250.  
  251.        If you have a conference whose files do not follow the ???????M.DEF
  252.        and ???????U.DEF naming convention for the message and user files,
  253.        you'll need to pass the full user filename when using the /N option:
  254.  
  255.           MAILFIX /O /K100 /NC:\RBBS\USERS C:\RBBS\MESSAGES
  256.  
  257.        These last five examples would replace your original message base
  258.        file with the fixed/purged/pruned message base.
  259.  
  260.  
  261.    Run MAILFIX without a command line to get a help screen.
  262.  
  263.    ------------------------------------------------------------------------
  264.  
  265.    TECHIE STUFF FOR THOSE WHO CARE:
  266.    -------------------------------
  267.  
  268.    If you run a mail system that utilizes RBBSMail, MsgToss, or OverMail
  269.    for echo mail processing, you're likely to have run across the fact that
  270.    the repair utility out of CONFIG (option #185) no longer works for you.
  271.    This is due to the fact that these mail processors place either a period
  272.    or a semicolon in the time field of the message header on every message
  273.    that they process.
  274.  
  275.    This just happens to be one of CONFIG's five "key fields" that it looks
  276.    at to determine whether or not the message is corrupt.
  277.  
  278.    These key fields are:
  279.  
  280.          Description                                  Should be
  281.          -------------------------------------------  ---------
  282.          The "killed" flag,                           Ascii 225 or 226 "ß,Γ"
  283.          the first separator in the 'time' field,     ":"
  284.          the second separator in the 'time' field,    ":", ".", or ";"
  285.          the first separator in the 'date' field,     "-"
  286.          and the last separator in the 'date' field.  "-"
  287.  
  288.    Therefore, this string of five characters is very important, and is what
  289.    will be displayed to you if the message needs repaired, and you specify
  290.    the "/v" option on MAILFIX's command line.  If you don't specify "/v" on
  291.    the command line, MAILFIX will do its best to fix the message, and
  292.    report "<fixed>".
  293.  
  294.    If you use a mail processor on your RBBS-PC message bases OTHER than
  295.    RBBSMail, MsgToss, or OverMail, and said mail processor *DOESN'T* use
  296.    a period or semicolon as its 'mark' in the second separator in the TIME
  297.    field, we'd sure like to hear about it so that we can attempt to make
  298.    MAILFIX compatible with your system.
  299.  
  300.    WHEN, AND HOW MAILFIX FIXES A MESSAGE:
  301.    -------------------------------------
  302.  
  303.    To determine whether or not a message is valid, MAILFIX looks at the
  304.    following in the message header:
  305.  
  306.      Message number             - Should never evaluate to zero.
  307.      Killed flag                - Should always be ASCII 225 or 226.
  308.      Number of 128-byte records - Should never evaluate to less than 1.
  309.  
  310.    If the message header passes these three tests, MAILFIX assumes it has
  311.    a valid message on its hands, and moves on to do one of three things:
  312.  
  313.      - Copy it (if it isn't marked as killed, and doesn't need fixed).
  314.  
  315.          MAILFIX will step through the message's records and write them to
  316.          the output file.
  317.  
  318.      - Fix it (if it isn't marked as killed).
  319.  
  320.          If, during all of its checks, MAILFIX finds that it has a valid
  321.          message on its hands, yet the five key characters mentioned above
  322.          DON'T MATCH what they're supposed to, the message header is
  323.          adjusted as follows:
  324.  
  325.            * Sets the "killed" flag to indicate that this is an active
  326.              message (Ascii 225) "ß".
  327.  
  328.            * Sets the TIME separators to:
  329.  
  330.                     :: - RBBS-PC  (un-scanned by RBBSMail/OverMail)
  331.                     :. - RBBSMail and MsgToss
  332.                     :; - OverMail
  333.  
  334.              You must have specified "/R" or "/O" on the command line
  335.              for the RBBSMail/OverMail checks to take place.
  336.  
  337.              If "/R" or "/O" is specified, MAILFIX is smart enough to
  338.              discover whether or not the message has been scanned by
  339.              either one of these mail processors yet, and will not mark
  340.              an un-scanned message with the special "." or ";" separator.
  341.  
  342.            * Sets both DATE separators to "-".
  343.  
  344.      - Purge it (if it's marked as killed).
  345.  
  346.          MAILFIX will skip the entire message (and its records) if the
  347.          message is marked as killed (ASCII 226) "Γ".
  348.  
  349.    If the message didn't pass the tests, MAILFIX assumes that this is not a
  350.    message header, reports to you as such, purges the offending record, and
  351.    moves on to the next record until it finds the next valid header.
  352.  
  353.    ------------------------------------------------------------------------
  354.  
  355.    *=- ABOUT MAILFIX and MESSAGE BASES with CARBON COPIES -=*
  356.        --------------------------------------------------
  357.  
  358.    MAILFIX *DOES* work with message bases that have been configured with
  359.    the new "carbon copy" feature of RBBS-PC v17.4.  MAILFIX does not go
  360.    through any special gyrations to look for multiple-recipient messages,
  361.    but it will not trash your message base, either.  When renumbering, it
  362.    will reset the message number in all "carbon copies".
  363.  
  364.    In the 3+ years of Mail Manager / MAILFIX's life thus far, we have
  365.    found that there are MANY utilities floating around out there that do
  366.    not strictly adhere to the RBBS-PC message format as-defined in the
  367.    documentation for our favorite BBS software.  MAILFIX was specifically
  368.    written to be as generic as possible, and to work with the widest
  369.    possible variety of RBBS-PC message bases.
  370.  
  371.    The only incompatibility with RBBS-PC v17.4 message bases is the
  372.    following scenario:
  373.  
  374.        The message base is configured with "carbon-copy" turned on, and
  375.  
  376.        1) - The very first header of the "carbon-copy" message is bad, or
  377.        2) - The very first header of the "carbon-copy" message is marked
  378.             as "killed".
  379.  
  380.        In the first case, MAILFIX will skip the "bad" message, and maybe
  381.        the one following it as well, until it can get its bearings and
  382.        find the next "good" message header.
  383.  
  384.        In the second case, MAILFIX will purge the entire message, even
  385.        if some of the other carbon copies have not been marked as killed.
  386.